Requirements Engineering Domain Dimensions

This doc gives my initial ideas on the dimensions/criteria for different genres of applications (or domains if you prefer), following my summary presentation at the Dagstuhl workshop. The application genres were • Engineering – control applications − large scale systems engineeringaircraft, chemical plants... • Administrative systems − large scale social systems (engineering ??) • User driven systems − unpredictable and emergent needs, individual and social scale − tools rather than applications • Product-style systemstransactional − ERPs, market driven requirements and satisfycing • Software products discretionary − life style, social-ware, entertainment, education, user experience As a taxonomy the categories are not orthogonal, e.g. office apps like Excel and be administrative and end user driven systems; however, the genres are just tools for thought about the criteria/ dimension which might usefully characterise different types of applications. My first shot follows: Ownershippersonal, organisational, governmental, single party, multi party. This begs the stakeholder question, the owner might be the purchaser/ procurer, but for social software who owns it the community (viz Facebook, Open source) Time scaleshort /long. Probably useful as it intersects with scale. Definitely a dimension but has a confound in versions, also reusable software that iterative augmented, when does one life morph into another. Constraints from the Physical/Social world. This is motivated by Michael J’s problem frames. Some systems are more bound by constraints (domain properties) emanating from the physical world whereas others suffer from human made constraints (laws and rules). Probably useful dimension Human-Physical and degree of constraint (hard-soft). Requirements freedomsMay not be dimensions or criteria, but more like ‘typical process pathways’ by which products set developed: market driven, contractual bespoke, legacy, incremental design, ERP composition, design by reuseCBSE, mash ups-EUD. Really a space of choice for developers, users and market influences. COTS, procurement literature has some input, I did a pathways article partially on this theme a long time ago Sutcliffe, A. G. (1996). A conceptual framework for requirements engineering. Requirements Engineering, 1(3), 170-189. Locus of designrelated to the requirements freedoms, expresses the dimension of involvement from professional to end users. Solo user, multi party communities,